WASI 0.3 y el Component Model: async nativo en WebAssembly, con ejemplos

WASI 0.3, la especificación que da a WebAssembly acceso estandarizado al sistema fuera del navegador, ha ido llegando durante 2026 con la pieza que le faltaba a WebAssembly desde siempre: I/O asíncrona nativa, integrada en el propio Component Model, sin callbacks ni trucos para simular concurrencia. Con eso resuelto, el Component Model deja de ser solo «puedo compilar Rust a Wasm» y empieza a funcionar de verdad como una forma de componer código escrito en lenguajes distintos.

El problema que había hasta ahora

Antes de WASI 0.3, una operación de red dentro de un módulo Wasm tenía que resolverse con polling manual o con una API de callbacks incómoda, porque el modelo de ejecución de WebAssembly era fundamentalmente síncrono. Cualquier lenguaje anfitrión con su propio modelo async (JavaScript con promesas, Python con asyncio, Rust con tokio) tenía que tender un puente artificial hacia ese mundo síncrono. Con async nativo en el Component Model, esa fricción desaparece: un componente Wasm puede exponer una función async y el anfitrión la trata como tal, sin adaptadores.

Un componente en Rust, expuesto con WIT

El Component Model describe la interfaz de un componente con WIT (Wasm Interface Type), un lenguaje de definición independiente del lenguaje de implementación:

package ejemplo:[email protected];

interface procesar {
  procesar-datos: async func(entrada: string) -> string;
}

world componente-procesador {
  export procesar;
}

La palabra clave async en la firma de la función es justo la novedad de WASI 0.3, antes no existía forma estándar de declarar que una función de un componente es asíncrona.

La implementación en Rust, usando el binding generado a partir de ese WIT:

use exports::ejemplo::procesador::procesar::Guest;

struct Componente;

impl Guest for Componente {
    async fn procesar_datos(entrada: String) -> String {
        // trabajo real: parseo, validación, transformación...
        entrada.to_uppercase()
    }
}

Consumido desde JavaScript, sin glue code manual

Desde el lado anfitrión, un runtime compatible con el Component Model expone ese componente como si fuera una función async nativa de JavaScript:

import { procesarDatos } from "./componente-procesador.js";

const resultado = await procesarDatos("hola mundo");
console.log(resultado); // "HOLA MUNDO"

No hay serialización manual, no hay que escribir el pegamento que convierte tipos de JS a tipos de Wasm y viceversa, el toolchain lo genera a partir de la definición WIT. Es la misma promesa que llevaba años prometiendo WebAssembly, «compila una vez, usa desde cualquier lenguaje», pero ahora con async de por medio sin que se rompa nada.

Composición políglota: tres lenguajes, un solo pipeline

La parte más interesante en la práctica es la composición de componentes escritos en lenguajes distintos dentro de un mismo flujo de trabajo. Un caso realista: lógica de negocio en Rust, procesado de datos en Python, orquestación en JavaScript. Cada pieza se compila a su propio componente Wasm, y un archivo de composición los conecta:

package ejemplo:[email protected];

world pipeline-completo {
  import ejemplo:procesador/procesar;
  import ejemplo:analisis-python/analizar;
  export ejemplo:orquestador/ejecutar;
}

Cada componente solo conoce la interfaz WIT del que consume, no el lenguaje en el que está escrito el otro lado. El componente Python no sabe que quien lo llama es Rust, ni falta que le hace.

Qué falta todavía

WASI 0.3 es un paso importante, no el final del camino. La propia comunidad habla de una posible versión 1.0 a finales de 2026 o principios de 2027, así que conviene tratar el ecosistema actual como estable para experimentar y para casos de uso concretos (procesamiento en el edge, plugins sandboxed, funciones serverless portables), pero todavía en movimiento en los detalles finos de tooling y en la madurez del soporte por lenguaje, que varía bastante entre Rust (el más maduro), Python, Go y JavaScript.

Para quien ya usa WebAssembly en producción, el cambio real de WASI 0.3 es que deja de hacer falta elegir entre async y componer módulos de distintos lenguajes: ahora se puede tener las dos cosas a la vez.

Relacionado: Kotlin/Wasm en 2026.